fix(datadog): restore LCP/FCP reporting by keeping the initial_load view alive - #1642

Studio has reported no LCP or FCP since 2026-07-04 (#1570) because it called datadogRum.startView twice on boot, and the second call destroyed the only view that can carry paint metrics. This removes the redundant call, which also fixes every initial page load being attributed to the view name /.

Under trackViewsManually: true the RUM SDK stays stopped until the first startView, adopts that call's options as its single initial_load view, and turns every later call into a route_change view (preStartRum.ts tryStartRum, trackViews.ts startView). Only an initial_load view runs trackInitialViewMetrics, so it is the only view that can ever carry LCP or FCP. useDatadog and useOnRouteLoadTracker both called startView, so the initial view was ended microseconds after it began.

For the human reviewer

1. Which of the two startView calls to delete. Kept useOnRouteLoadTracker's, deleted useDatadog's. The alternative — keep useDatadog's and gate the tracker to fire only on subsequent routes — restores vitals equally well but leaves every initial_load view named /, because useDatadog named views from window.location.pathname and Studio uses hash routing. Deleting useDatadog's call fixes both defects with one edit. Fully reversible; a change of mind costs one commit.

2. The boot-redirect concern an earlier draft of this description left to you is now settled, and it splits in two. Measured against the real TanStack router in jsdom, not reasoned about:

   • Ordinary signed-out deep link — one view, no problem. authStore.getAllConnections() synthesizes { user: null, isLoading: false } for OverallAppSignIn whenever the Studio:PotentiallyAuthenticated record has no entry for it, so dashboardLayout.beforeLoad throws its redirect during the router's initial load and the root component never commits the deep-link location. Exactly one startView, named /sign-in/. datadogBootView.test.tsx now pins this.
   • Expired session — two views, and I am deliberately leaving it. With the flag present, getAllConnections() returns the record untouched and the key is simply absent, so beforeLoad short-circuits on auth && rather than on isLoading. The deep link renders, then auth resolves and AppRouted's router.invalidate() drives the redirect. The judgment: that second view is a genuine navigation, and RUM ending the current view on navigation is correct behaviour, not a bug — suppressing it would cost real route_change tracking to buy a metric. Note the window here is a network round trip, not the 0.3 ms of the bug being fixed, and this PR takes such a session from three views to two.

   The residual risk if you disagree: expired-session sessions may still under-report vitals. Say the word and I will extend this PR.

3. RUM now starts on first route render rather than on App mount — and there is a narrow telemetry consequence. This follows from (1): the first startView is what starts the SDK, and the tracker lives in StudioCloud, the root route component. Gemini flagged this as a data-loss major on the theory that some routes render outside the cloud root; that is refuted — rootRouteTree is rootRoute.addChildren([...]), so every route renders inside StudioCloud, including defaultNotFoundComponent and defaultErrorComponent. What remains is genuinely narrow: if the root component or the router itself fails catastrophically before rendering, no view ever starts and that session reports nothing, where previously useDatadog would already have started RUM from outside the router. If you want that closed, the clean way is useDatadog keeping a startView and the tracker calling setViewName() on its first run instead of startView — the SDK exposes it (rumPublicApi.ts:118) and it renames the initial view without ending it. I did not do it because it adds first-run state for a failure mode I cannot reproduce, but it is the strictly-better design if you judge the boot-error window worth it.

4. StudioLocal does not call the tracker, so local Studio never starts a view. Pre-existing and correct — enabled is !import.meta.env.DEV && !isLocalStudio, so RUM is fully disabled there and no view would have been sent anyway. Flagged only because the asymmetry reads like an oversight in the diff.

Addressed from PR review: gemini-code-assist found the mocked useRouter returned a fresh object per render. That was not cosmetic — because the tracker's effect lists router in its deps, the effect re-fired on every render and the subsequent-navigation assertion was vacuous, holding even without location.href as a dependency. Fixed in ff3635b0 with a single stable router identity, plus an assertion that a no-op re-render produces no view; that assertion fails against the old mock, so it stays guarded.

Addressed from pre-push review: codex caught that the new AGENTS.md note credited getAllConnections() with reporting isLoading: true for a persisted session. It does not — that value comes from getConnectionById, a different API. Corrected in e53ca443; the two outcomes were right, the mechanism was not.

Declined, three rounds running: a nit that the diff's five comments narrate. I audited each against the zero-new-comments default and kept all five, because each is a constraint a future reader would otherwise delete along with the guard it protects — the datadog.ts comment marks the absence of a startView at the exact line someone would re-add one; the router-mock comment is why the mock is a single instance with a getter, which "simplifying" back to a literal makes the navigation tests vacuous again; datadog.test.tsx:41 is why the suite uses a dynamic import (a top-level one leaves enabled false and every assertion passes for nothing); :117 is why a re-render that changes nothing is not dead code; and datadogBootView.test.tsx:26 is why the real routes there are load-bearing. Overturn any of them cheaply if you disagree — the reasons are all one line.

Verified and closed, recorded here so you don't re-derive them. Both re-checked this round against the installed @datadog/browser-rum-core@7.8.0, not the published source:

• gemini's child-before-parent effect-ordering concern (the tracker in a child firing startView before useDatadog's init) is safe. onReady(callback) { callback() } — browser-core/cjs/boot/init.js:8, synchronous. A startView arriving before init is buffered into bufferApiCalls, recorded as firstStartViewCall, and adopted as initialViewOptions when tryStartRum() later succeeds — browser-rum-core/cjs/boot/preStartRum.js:121-133 and :33-39. This is the SDK's designed path for trackViewsManually, not a tolerated accident.
• gemini's claim that datadogBootView.test.tsx fails to catch useDatadog reintroducing a boot startView is true of that file and irrelevant — the two-hook tree case is the first test in datadog.test.tsx, and it is the one that goes red under exactly that mutation. The two files guard different invariants on purpose.
• gemini's second-round crash-safety minor — "any crash above the router tree loses all telemetry" — is the same window as item (3) above, independently rediscovered. No new information, but it does corroborate that (3) is the right thing to have disclosed rather than buried.
• Not tested on purpose: the expired-session path from item (2). Reproducing it in a test means reimplementing AppRouted's context-and-invalidate() wiring in the harness, which tests the harness rather than the product. I measured it with a throwaway probe instead — two views, matching the AGENTS.md note — and shipped only the test whose reals are all production code.
• Not taken: narrowing the tracker's effect deps from router to location.href — a pre-existing line this PR doesn't touch, with a hypothetical trigger, so it stayed out under YAGNI.

Verification

Route: live reproduction against the real SDK, plus a real-router regression test — the change is not observable through the e2e suite (RUM is disabled in dev and test builds, and no e2e spec touches it).

Served the shipped @datadog/browser-rum@7.8.0 bundle over HTTP and replicated Studio's boot sequence (init in a deferred callback, startView inside onReady, then a second startView in the same flush), with a beforeSend that captured each assembled event and returned false so nothing reached Datadog:

• Two calls (current stage behaviour): the calls land at t=78.2ms and t=78.5ms — 0.3ms apart. The initial_load event ships with dom_complete: 79ms and no lcp, no fcp, then a route_change view takes over.
• Production agrees: of 200 raw initial_load views over 7 days, dom_complete 17, fcp 2, lcp 0. All 880 initial_load views that week are named / — one facet bucket — while route_change views carry proper route names.

Regression tests. datadog.test.tsx (4 cases, mocked router): mounts both hooks in the production nesting and asserts exactly one startView; pins its name to the translated route; keeps an isolated useDatadog case to localise a failure; and asserts a further named view per subsequent navigation. datadogBootView.test.tsx (1 case, real router) boots the real rootRoute and the real dashboardLayout guard on a signed-out deep link and asserts one startView named /sign-in/ — this is the file that guards the invariant the whole fix rests on, that the tracker is still mounted at the root route.

All mutation-verified rather than merely green: re-adding the deleted block turns the tree-level and isolated cases red; dropping useOnRouteLoadTracker() from StudioCloud takes the boot test to 0 calls; and disabling the redirect guard moves its asserted name to the deep link, so the name assertion is load-bearing too.

Gates (Node 24.19.0, all exit 0, re-run after every review round): vitest run 323 files / 2626 passed, tsc -b, oxlint, dprint check, and pnpm test:e2e:docker (4 passed, 4 skipped — the skipped specs need roundtrip credentials). Script mapping: Studio has no test:unit:main/test:unit:resources/test:integration:all; the equivalents are test (vitest) and test:e2e:docker (Playwright).

No documentation PR. Nothing user-facing changes — this is internal telemetry wiring. The durable findings went to AGENTS.md instead, which is where the next agent to touch RUM will look.

Not proven, and the thing to watch post-merge: that the fix restores LCP/FCP end-to-end. Every browser surface available locally reports visibilityState: 'hidden', which emits zero paint and LCP entries, and trackFirstHidden would discard them anyway — so vitals read as absent whether the fix works or not. The cheap confirmation is @view.largest_contentful_paint coverage on initial_load views after this deploys: it should go from 0% to a non-trivial share. Do not close #1570 on merge — close it on that measurement, which is why this description says "Refs" and not "Fixes". Note #1405's baseline predates this and needs re-framing rather than just fresh data — its "/ view" was every deep-link entry conflated into one bucket.

Coverage caveat. The Harper domain adjudicator has failed on every round of this PR (exit-1, zero-byte log — a known failure on this machine), so no outside finding here was ever machine-adjudicated; I triaged them against the installed SDK and the route tree, which is why several are recorded as refuted/verified rather than fixed. Both Cursor lenses are structurally unavailable to this PR: cursor-review refuses any diff that touches AGENTS.md, and this one does. What did run independently is codex + gemini, both on the final code.

Complexity: medium

_{Review-Coverage: authored=claude; ran=gemini,codex; declined=cursor-grok,cursor-composer,domain; rounds=8 @ e53ca44}

_{Human-Review-Need: 4 @ e53ca44}